A multiprocessor computing system requires a manner of granting, to one processor at a time, exclusive access to protected resources. In a bus-based multiprocessor, a frequent approach is to augment the system bus protocol. This approach is popular because the system bus must already have a method of arbitrating among the processors, requiring only the expression of arbitration commands through the instruction set.
A variation on this bus access technique is to allow a "winning" processor to stop all other bus activity until that processor is finished with its accesses. This approach certainly provides the basis for mutual exclusion, but in inhibiting all bus activity, the approach can significantly degrade system performance. This can be compensated for somewhat by permitting only the simplest of actions while arbitration is frozen: for example, "test and set". A second disadvantage of this approach is that only one lock can exist at a time.
More sophisticated locking techniques use the bus arbitration protocol only as a means of allowing one contender at a time access to a "lock" resource that, once secured, cannot be acquired by a second processor. In other words, the bus arbitration mechanism is only the doorway to the resource lock, and there may actually be multiple locks, each securing a different resource.
If there is to be a system bus lock that ca be held by only one processor at a time, the natural question is how to ensure fairness in the competition for acquiring the lock. One method is to rely upon the basic fairness of the bus' primary arbitration method. However, this approach has two shortcomings. The first is that securing the bus may not necessarily assure securing the lock. This can result in significant bus time wasted in lock acquisition retries. The second shortcoming is that because the bus lock holding period may extend over many bus arbitration cycles, any fairness guarantees that the primary bus arbitration protocol can offer has been lost. One manner of solving both these problems is to use a random and infrequent retry.